Using a third party dynamic qr code on a personal mobile device to complete a transaction at an atm

ABSTRACT

Disclosed herein are system, method, and computer program product embodiments for using a third party dynamic QR code on a personal mobile device to complete a transaction at an ATM. The customer may stage a transaction using a mobile application on a mobile device. Upon the staged transaction being authenticated and approved, a machine readable image may be transmitted to the mobile device. When the customer visits the ATM, the machine readable image on the mobile device may be captured by the ATM and sent to an application server from the ATM. The application server may associate the ATM with the staged transaction that is staged using the mobile application, and send instructions to the ATM to dispense cash according to the staged transaction.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a Continuation Application of U.S. patentapplication Ser. No. 16/877,091, filed on May 18, 2020, the contents ofwhich are incorporated herein in their entireties.

BACKGROUND

Automated teller machines (ATMs) have successfully served bankingcustomers to complete their banking transactions without stepping insidethe branch office and interact with a real human being. The customer canswipe or insert a bank issued ATM/Credit/Debit card at ATM and enter anassociated personal identification number (PIN) to perform transactionssuch as withdrawing cash, depositing cash, or performing balanceinquiries. These transactions at the ATM are not possible without thecustomer having the ATM/Credit/Debit card in his/her possession.

Employees of employers who collect cash upon delivery of items such asparcels or food are known as runners. The runners are required todeposit cash in the account of the employer. For the runners to depositcash during normal banking hours interacting with a teller may beconvenient but time-consuming. However, if the runner is not carrying anATM/Credit/Debit card of the employer's account, it is impossible forthe runner to deposit cash using an ATM.

BRIEF DESCRIPTION OF THE DRAWINGS/FIGURES

The accompanying drawings, which are incorporated herein and form partof the specification, illustrate the present disclosure and, togetherwith the description, further serve to explain the principles of thedisclosure and enable a person skilled in the relevant art to make anduse the disclosure.

FIG. 1 illustrates a block diagram of an example environment in whichsystems and/or methods for using a third party dynamic quick response(QR) code on a personal mobile device to complete a transaction at anATM may be implemented according to an example embodiment.

FIG. 2A illustrates a screen of a mobile application according to anembodiment.

FIG. 2B illustrates a screen of a mobile application according to anembodiment.

FIG. 2C illustrates a screen of a mobile application according to anembodiment.

FIG. 2D illustrates a screen of a mobile application according to anembodiment.

FIG. 2E illustrates a screen of a mobile application according to anembodiment.

FIG. 2F illustrates a screen of a mobile application according to anembodiment.

FIG. 2G illustrates a screen of a mobile application according to anembodiment.

FIG. 2H illustrates a screen of a mobile application according to anembodiment.

FIG. 3A illustrates a flowchart of a process for using a third partydynamic quick response (QR) code on a personal mobile device to completea transaction at an ATM according to an embodiment.

FIG. 3B illustrates a flowchart of a process for using a third partydynamic quick response (QR) code on a personal mobile device to completea transaction at an ATM according to an embodiment.

FIG. 3C illustrates a flowchart of a process for using a third partydynamic quick response (QR) code on a personal mobile device to completea transaction at an ATM according to an embodiment.

FIG. 4 illustrates an exemplary computer system according to anembodiment.

The drawing in which an element first appears is typically indicated bythe leftmost digit or digits in the corresponding reference number. Inthe drawings, like reference numbers may indicate identical orfunctionally similar elements.

DETAILED DESCRIPTION

Smartphones have changed the lives of people to perform various acts,such as receiving news, shopping, entertainment, social life, banking,etc. People earlier were used to going inside the bank branch andinteract with a teller to withdraw or deposit cash. Then, ATM came, andpeople can withdraw or deposit money at the ATM. People can also know anavailable balance in their accounts with the bank. But, with thesmartphone, people can do many of the transactions that required them toleave their home earlier, now from their living room or bedroom. Forexample, a person has a bank account at a bank; then a person candownload a mobile application on their mobile device. The mobileapplication allows the person access to his/her bank account with thebank. Using the mobile application, the person can deposit a cheque intotheir account by uploading an image of a front and a back of the cheque.The person can also transfer money from one account to another account,to another person, and/or to another account at a different bank, etc.The mobile device on which the mobile application may be downloaded maybe a smartphone, a phone, a tablet, a laptop, a desktop, or any othercomputing device that may allow interacting with a bank account using amobile application or a native browser application of the mobile device.

For example, a bank account holder has downloaded a mobile applicationon his/her mobile device. Using the mobile application, the bank accountholder can perform operations as described above. However, using themobile application, the bank account holder can not receive cash from ordeposit cash to his/her bank account. That would require the bankaccount holder to go to the bank or an ATM to receive or deposit cash tohis/her bank account. Additionally, performing transactions such aswithdraw or deposit cash, check account balance, etc., at the ATM, abank-issued ATM/Debit/Credit card is required to authenticate and gainaccess to the bank account. However, if the person is not carrying thebank issued ATM/Credit/Debit card, no transaction can be performed atthe ATM.

In this disclosure, the bank account holder may be an authorized user ofthe bank account. The authorized user may be the runner, a person who isrequired to deposit cash in the employer's bank account, as describedabove. An owner of the account, for example, an employer, may provideinformation of one or more runners as authorized users of the account.The information provided for the authorized users of the account mayinclude phone numbers of the mobile devices used by the runners,personal details of the runners, user id and password associated withthe authorized user account. The personal details of the runners mayinclude social security number, date of birth, place of birth, etc.Accordingly, the runner may download the mobile application to interactwith the account from his/her mobile device. The runner may log in tothe mobile application and interact as the owner of the account.However, the allowed features/operations may be limited for the mobileapplication installed on the mobile device of the runner. For example,the policy set by the bank account holder may limit withdrawal of themoney based on the amount, frequency, and/or time, etc. The bank accountholder and the authorized user may also be referenced as a mobileapplication user in this disclosure.

The present disclosure makes a transaction at the ATM possible withoutthe use of the bank issued ATM/Debit/Credit card. By way of anon-limiting example, the mobile application downloaded on the mobiledevice may allow the mobile application user to stage a transaction tobe performed later at the ATM. Further, examples provided in thisdisclosure may refer to a mobile phone as a mobile device, but thisdisclosure is not limited to the phone or the mobile phone as a mobiledevice.

Since the transaction is staged in advance, the mobile application usermay not be required to use the bank issued ATM/Credit/Debit card at theATM. The mobile application user may be authenticated using the loginand/or password to access the mobile application on the mobile device.The mobile application user may be authenticated using biometricinformation such as fingerprint, retina/iris scanning, facialrecognization, etc. The mobile application user may be authenticatedusing two-factor authentication in which a code may be sent to a mobiledevice associated with the bank account, and the code sent to the mobiledevice associated with the bank account may be required to send backfrom the mobile device for verification.

After successful authentication of the mobile application user, themobile application user may stage the transaction, which may bereferenced as a prestaged transaction in this disclosure because thetransaction is staged using the mobile application to be completed laterat the ATM. The prestaged transaction, for example, maybe forwithdrawing cash from a savings account. Using the mobile application,the mobile application user may select the savings account and amount ofmoney to withdraw from the savings account. As the mobile applicationuser selects the amount of money to withdraw from the savings account,the mobile application may send one or more messages to an applicationserver, which provides the mobile application access to the bankaccount. If there is sufficient balance, withdrawal of the requestedmoney may be preapproved. The mobile application user may then beinstructed to go to an ATM and use his/her phone used in prestaging thetransaction to collect the requested money.

Because the mobile application user has used his/her phone, theapplication server may send a machine readable image to the phone usedto set up the prestaged transaction. The machine readable image may be abar code or a Quick Response (QR) code. The machine readable image sentto the phone used to set up the prestaged transaction may uniquelyidentify the prestaged transaction. Further, the machine readable imagemay be periodically refreshed by the application server.

Accordingly, when the user visits an ATM to complete the prestagedtransaction, the prestaged transaction may now be required to associatewith the ATM. Once the prestaged transaction is associated with the ATM,the ATM may be instructed to dispense the cash requested in theprestaged transaction.

In order to associate the prestaged transaction with the ATM, the mobileapplication user may be instructed to present the machine readable imagesent to the phone before a camera of the ATM. The camera of the ATM maybe integrated with a body of the ATM, or the camera may be in the sameenclosure as the ATM. As the user presents the machine readable imagebefore the camera, the machine readable image on the phone may becaptured by the ATM. The ATM may then send the captured machine readableimage along with an ATM identifier to the application server. The ATMidentifier uniquely identifies the ATM. The ATM identifier alsoidentifies a physical location of the ATM, i.e., bank branch, navigablegeographical address, and/or network identification of the ATM, etc.Therefore, when a message comprising the ATM identifier and the machinereadable image is received at the application server from the ATM, theapplication server may associate the prestaged transaction and the ATMbased on the machine readable image captured by the camera of the ATMand the ATM identifier. The application server may then send one or morecommands to the identified ATM to complete the identified prestagedtransaction. As a result, the mobile application user may receive therequested money from the ATM without using the bank issuedATM/Credit/Debit card.

Various embodiments to use a QR code on a mobile device to complete atransaction at an ATM, as described above, will now be discussed withrespect to the corresponding figures. The disclosure is not limited toan ATM to release the cash, but this disclosure applies to any kiosk toserve a product or any transaction through the use of a QR code on amobile device, based on the prestaged transaction. Further, thedisclosure is not limited to the prestaged transaction setup using themobile application by the mobile application user alone.

FIG. 1 illustrates a block diagram of an example environment 100 inwhich systems and/or methods described herein may be implemented. Theenvironment 100 may include a user equipment (UE) device 102. The userequipment device 102 may be a mobile phone, a smartphone, a tablet, alaptop, or any other computing device of the customer. The customer maydownload a mobile application on the UE device 102. The mobileapplication on the UE device 102 may allow the customer to set up atransaction in advance for later execution at an automated tellermachine (ATM) 114. The transaction set up in advance for later executionat the ATM 114 may be referenced as a prestaged transaction in thisdisclosure. In some embodiments, instead of the mobile application onthe UE device 102, the customer may set up the prestaged transactionusing a web application on the UE device.

In some embodiments, the ATM 114 may include a keyboard, a card reader,a display, a slot to dispense cash, and a slot to receive cash, acheque, or an envelope. The ATM 114 may also include a camera 103installed on the body of the ATM 114. The camera 103 may be integratedwith the body/frame of the ATM 114. The ATM 114 may include afingerprint pad, and/or another appropriate system to collect biometricor other information from the customer for various purposes, including,for example, authentication of the user, etc.

In some embodiments, the ATM 114 may include a display screen, a slot todispense cash, and a slot to receive cash, a cheque, or an envelope. TheATM 114 may include one or more physical buttons for the customer torequest for help. The ATM 114 may also display one or more buttons thatare clickable displayed on the display screen of the ATM 114.

In some embodiments, the environment 100 may include another userequipment (UE) device 118. Similar to the UE device 102, the UE device118 may be a mobile phone, a smartphone, a tablet, a laptop, or anyother computing device of the customer. The UE device 118 may alsoinclude a camera, which may be integrated with the UE device 118 or apluggable device into the UE device 118. The UE device 118 may be withan associate or a customer care agent, for example, of a bank to assistthe customer at the ATM 114. The UE device 118 may have a mobileapplication installed on it that may be different from the mobileapplication installed on the UE device 102 of the customer. Theassociate or the customer care agent may thus assist the customer asdescribed in detail below. The mobile application on the UE device 118may be referenced as a customer care mobile application in thisdisclosure.

In some embodiments, both the UE devices 102 and 118 may communicatewith a micro-service repository 106 over a secure interface 104. Thesecure interface 104 may be a firewall or a virtual private network. Thesecure interface 104 may be a secure session layer on the UE devices 102and 118 and the micro-service repository 106 for secure communication.By way of non-limiting example, the mobile application on the UE device102 and/or the customer care mobile application may interact with a bankaccount by sending and receiving messages with the micro-servicerepository and cardless services 108 over the secure interface 104.

In some embodiments, the micro-service repository 106 may be anapplication, which receives messages from the UE devices 102 and/or 118for further processing. The micro-service repository 106 may implementbusiness logic for various features and/or functionality. Themicro-service repository 106 may be an application program interface(API) that processes messages received from the ATM 114, and the UEdevices 102 and/or 118. The micro-service repository 106 may also sendmessages to the ATM 114, and the UE devices 102 and/or 118 based on theprocessed received messages. The micro-service repository 106 may beinstalled on one or more servers, which may be a server described belowwith reference to FIG. 4.

In some embodiments, the micro-service repository 106 may send thereceived messages after initial processing to cardless services 108. Thecardless services 108 may further process the received messages. Thecardless services 108 may have access to one or more databases, whichmay include a record(s) of an account(s) of the customer(s).

In one example, the UE device 102 may set up a prestaged transaction towithdraw sixty dollars from his bank account using a mobile applicationon the UE device 102. The UE device 102 may communicate with themicro-service repository 106 over the secure interface 104. Themicro-service repository may receive one or more messages from the UEdevice 102 in connection with the prestaged transaction. The receivedmessage(s) from the UE device 102 may include for example an accountnumber, a PIN, a transaction type (withdraw or deposit cash), amount ofthe transaction. The received message(s) from the UE device 102 may alsoinclude an identifier of the UE device 102, or the UE device 102 mayinclude the identifier of the UE device 102 in each message to themicro-service repository 106. The micro-service repository may send thereceived message(s) from the UE 102 after initial processing to thecardless services 108 for further processing. The further processing mayinclude verification of the PIN, verification of the UE device, and/orauthorization of the prestaged transaction.

In some embodiments, cardless services 108 allow mobile device 102 tointeract with an ATM 114 without the need to have a physical ATM card asan authentication mechanism for the account holder. The cardlessservices 108 may verify that the same person who is an account holderowns a phone number associated with the UE device 102 associated withthe prestaged transaction. The cardless services 108 may send one ormore API messages to a phone service provider to retrieve ownershipinformation of the phone number associated with the UE device 102. Theretrieved ownership information from the phone service provider may bethe name of the person to which the phone number may be registered. Thecardless services 108 may verify that the name of the owner of the phonenumber associated with the prestaged transaction and the owner of theaccount associated with the prestaged transaction are same. Theretrieved ownership may also include social security number, date ofbirth, an address, etc. to verify against the record(s) of the accountassociated with the prestaged transaction.

In some embodiments, after successful authentication of the prestagedtransaction, the cardless services 108 may also verify other informationdepending on the transaction type before authorizing the prestagedtransaction. The other information verified by the cardless services 108may include transaction history of the account, available balance, alimitation(s) or a restriction(s) on a transaction(s) for the account,etc. The limitation may be a cash withdrawal limit, e.g., a maximum oftwo-hundred dollars withdrawal per day, only three transactions per day,etc. If the prestaged transaction is not in violation of any policy setfor the account associated with the prestaged transaction, the prestagedtransaction may be authorized, and an appropriate message may be sent tothe UE device 102 via the micro-service repository 106 over the secureinterface 104. The appropriate message sent to the UE device 102 mayindicate the customer that the prestaged transaction is authorized andthe user may visit any ATM to complete the transaction.

In some embodiments, the message may also include a list of ATM(s) basedon a location of the customer. If the location service has been enabledon the UE device 102, message(s) between the UE device 102 and themicro-service repository 106 may include a location of the UE device102. The location of the UE device 102 may be determined using Wi-Fi,and/or a global positioning system (GPS). The location of the customer,i.e., the UE device 102, may be used to prepare a list of ATMs based onthe geographic proximity of each ATM from the location of the UE device102. The location of the customer, i.e., the UE device 102 may also beused to determine if the UE device 102 is at the same location as theATM 114.

In some embodiments, the ATM 114 may be communicatively coupled with thepairing service 110, the cardless services 108, and the micro-servicerepository 106 via an ATM middleware 112. The ATM middleware 112 similarto the secure interface 104 enables secure communication with the ATM114 from the pairing service 110, the cardless services 108, and/or themicro-service repository 106. The pairing service 110 and the ATM 114are shown to have a separate path to display machine readable image 116on the ATM 114, the pairing service 110 and the ATM 114 may communicatevia the ATM middleware 112 to send (periodically) the ATM identifier tothe ATM 114 from the pairing service 110.

In some embodiments, when the customer approaches an ATM after the setupof the prestaged transaction using the mobile application on the UEdevice 102, the mobile application may display a machine readable image116 on the screen of the UE device 102. The machine readable image 116may be a barcode. The barcode may be a quick response (QR) code. Thebarcode displayed on the display of the UE device 102 may beone-dimensional (1D) or two-dimensional (2D). The 2D barcodes mayinclude rectangle, dots, hexagons, or any other geometric pattern. Themachine readable image 116 may uniquely identify the prestagedtransaction. For each prestaged transaction, a unique machine readableimage may be generated by a pairing service 110.

Further, for the prestaged transaction, the machine readable image maybe refreshed periodically to avoid fraud. Thus, the machine readableimage may be valid, for example, thirty seconds. And, so at every thirtyseconds, a new machine readable image may be generated that may be usedto identify the prestaged transaction.

In some embodiments, the pairing service 110 may generate the machinereadable image when requested by the cardless services 108 uponsuccessful authorization of the prestaged transaction set up via themobile application on the UE device 102. The pairing service 110 maysend the machine readable image to the UE device 102 via cardlessservice 108 and micro-service repository 106 over the secure interface104.

In some embodiments, the pairing service 110 may generate the machinereadable image for the prestaged transaction and send the generatedmachine readable image to the cardless services 108. The cardlessservices 108 may then send the machine readable image to the UE device102 via the micro-service repository 106 over the secure interface 104.The pairing service 110 may also periodically generate a new machinereadable image associated with the prestaged transaction to avoid fraud.The pairing service 110 may also store information of the machinereadable image and the associated prestaged transaction as a pair in adatabase (not shown). Because each machine readable image generated bythe pairing service 110 is valid for a configurable time period, thepairing service 110 may update the record of the association of theprestaged transaction and the machine readable image. The pairingservice 110 may be a process on one or more computing devices. Thepairing service may be implemented as a software, a hardware, and/or amodule.

Accordingly, when the customer who has set up a prestaged transactionand is now at the ATM 114, the customer may launch the mobileapplication on the UE device 102. The mobile application on the UEdevice 102 may display the machine readable image generated by thepairing service and transmitted to the UE device 102. The camera 103 mayalways be on and may be looking for the machine readable image to scan.As the UE device 102 displays the machine readable image 116, the camera103 may scan the machine readable image 116 and may send an APImessage(s) to the micro-service repository over a secure connectioncreated by the ATM middleware 112. The API message(s) from the ATM 114may also include an ATM identifier that may be used to identify the ATMand physical location of the ATM. The pairing service 110 mayperiodically assign a different ATM identifier to the ATM 114 thenassigned previously. The pairing service 110 may transmit the currentATM identifier to the ATM 114 via the ATM middleware 112.

In some embodiments, the UE device 102 may be required to have alocation service enabled and send a current location of the UE device102 while communication to the micro-service repository 106 and/orcardless services 108 over the secure interface 104. The currentlocation of the UE device 102 may be used to detect fraud, for example,by comparing the current location of the UE device 102 to the physicallocation of the ATM 114 as determined based on the ATM identifier. Ifthe physical location of the ATM 114 and the current location of the UEdevice 102 do not match, the prestaged transaction may not be permittedto complete at the ATM 114.

If the prestaged transaction has been denied, the appropriate messagesent to the UE device 102 may indicate the prestaged transaction hasbeen denied, and may indicate what the customer can do to resolve theissue that caused denial of the prestaged transaction, for example, calla customer care number, or chat with a customer care agent, etc.

In some embodiments, the ATM 114 may be equipped with a Bluetooth and/orWi-Fi system for periodic transmission of a beacon signal(s). Therefore,when the customer with UE device 102 comes within proximity of the reachof the beacon signal(s), a message may be sent to the UE device 102 as anotification to complete the prestaged transaction or any othertransaction at the ATM 114.

In some embodiments, the prestaged transaction may be associated with adevice identifier of the UE device 102. The device identifier of the UEdevice 102 may be an international mobile equipment identity (IMEI), amobile equipment identifier (MEID), an electronic serial number (ESN),etc. The device identifier of the UE device 102 may be used to search oridentify the prestaged transaction. For example, the prestagedtransaction fails at the ATM 114 because there is not sufficient cash atthe ATM 114. The customer may be displayed a message on the display ofthe ATM 114 and/or the UE device 102 to indicate there is not sufficientcash. However, the customer may be willing to take less than the amountrequested in the prestaged transaction. The customer may seek assistancefrom the customer care agent at the UE device 118 from an option on themobile application. The message sent from the UE device may include thedevice identifier, which may be used to search and/or verify theprestaged transaction. The customer care agent at the UE device 118 thenassists the customer to resolve the issue and complete the prestagedtransaction at the ATM 114.

The machine readable image 116 on the display of the UE device 102 isunique and may be associated with the prestaged transaction. The machinereadable image may also include details of the prestaged transaction asdata. Based on the scanned image received in the message from the ATM114, the micro-service repository and/or the cardless services 108 mayidentify the prestaged transaction. Further, the message from the ATM114 may also include the ATM identifier assigned to the ATM by thepairing service 110. Based on the ATM identifier received in the messagefrom the ATM 114, the ATM and its physical location may be determinedusing the pairing service 110. The pairing service 110 may keep anup-to-date record of the machine readable image being displayed on theUE device 102, associated prestaged transaction, and for the time periodfor which the machine readable image is/was displayed. The pairingservice 110 may keep an up-to-date record of the ATM identifier assignedto each ATM and the time period for which the assigned ATM identifier isvalid. Accordingly, the micro-services repository 106 and/or thecardless services 108 may correctly identify the prestaged transactionand the corresponding ATM at which the customer is to complete theprestaged transaction.

If the scanned image and the ATM identifier received in the message fromthe ATM 114 matches with the record of the pairing service 110, thepairing service may provide details of the ATM identifier and theprestaged transaction to the cardless services 108, so that the cardlessservices 108 may communicate with the ATM, for example, the ATM 114, tocomplete the prestaged transaction. The communication to the ATM 114 maybe via the ATM middleware 112, and may through micro-service repository106. Accordingly, the cardless services 108 and/or the micro-servicerepository 106 may send one or more API messages to the ATM 114 todispense cash according to the authorized prestaged transaction. If theprestaged transaction is for a cash deposit, the API message to the ATM114 from the micro-service repository 106 and/or the cardless services108 may be to open the slot to receive cash, a cheque, and/or anenvelope. The API message to the ATM 114 may also include commands toverify cash deposit, a signature on the cheque, etc., and print areceipt.

In some embodiments, if execution of the prestaged transaction fails atthe ATM 114, the cardless service 108 and/or the micro-servicerepository 106 may send a message to the UE device 102 and/or the ATM114. The message to the UE device 102 and/or the ATM 114, when theexecution of the prestaged transaction fails, may ask the customer howto seek assistance or help from a customer care agent. The customer mayseek assistance from the customer care agent using the one or morephysical buttons on the ATM 114 or the one or more clickable buttonsdisplayed on the display screen of the ATM 114. When the customerrequests for help from the customer care agent, the customer care agentat the UE device 118 may be notified by the ATM 114 by one or more APImessages from the ATM 114 to the micro-service repository 106 and/or thecardless services 108 over the secure connection provided by the ATMmiddleware 112 and the secure interface 104.

The customer care agent at the UE device 118 may assist the customerusing a mobile application installed on the UE device 118 to assistcustomers. The customer care agent at the UE device 118 may set up avoice/video communication with the customer to resolve issues. Thecustomer care agent may verify information of the customer using pasttransaction history, personal details of the customer that the customerhas provided earlier, prepopulated security questions and answers,verifying personal documents, etc. The personal details of the customerthat the customer has provided earlier include, for example, a socialsecurity number (SSN), date of birth, place of birth, marriageanniversary, name and/or other personal details of family members,residential and/or business address, etc. The personal documents thatmay be verified by the customer care agent at the UE device 118 may be adriver's license, a passport, etc. Upon successful authentication of thecustomer, the customer care agent at the UE device 118 may send anappropriate API message(s) to the ATM 114 via the micro-servicerepository 106 and/or the cardless services 108 over the secureconnection provided by the secure interface 104 and the ATM middleware112 to complete the prestaged transaction. The customer care agent atthe UE 118 may update the account associated with the prestagedtransaction to indicate the override of the automatic process flow,which may provide the customer benefit of not having the problem at theATM 114 again for a configurable period of days, for example, thirtydays. By way of non-limiting example, the customer is stepped up forthirty days. The customer care agent at the UE 118 may update theaccount with a token that may expire after the configurable period ofdays.

In some embodiments, the environment 100 may include an ATM adminconsole 120 communicatively coupled with the ATM 114 via the ATMmiddleware 112. Using the ATM admin console 120, a bank associate or acustomer care agent may securely send instruction(s) or command(s) tothe ATM 114 to complete the prestaged transaction. The ATM admin console120 may select an ATM from a plurality of ATMs to securely send theinstruction(s) or the command(s) to assist customers in need of help tocomplete the prestaged transaction or any transaction at the ATM. TheATM admin console may be located at a remote bank facility, such as acustomer care center by way of non-limiting example.

As described earlier, the ATM 114 may include one or more physicalbutton or clickable button on the display of the ATM 114 for thecustomer to request help from the customer care agent. While completingthe prestaged transaction or any transaction, the customer may requesthelp from the customer care agent using the physical button or clickablebutton on the display of the ATM 114. By way of non-limiting example,the customer has setup the prestaged transaction, but when the customerarrived at the ATM 114, the customer forgot to bring the mobile deviceused to setup the prestaged transaction. The customer in such casecannot complete the prestaged transaction without help from the customercare agent.

Accordingly, when the customer requests help, the customer care agentmay receive a call or a distress signal from the ATM. The customer careagent may answer the call or the distress signal from the ATM, andauthenticate the customer using security questions on the profile of thecustomer on bank records. The customer care agent may also authenticatethe customer asking questions to the customer based on recenttransaction history. The customer care agent may also authenticate thecustomer requesting the customer to show an identification document suchas driver's license, passport, etc. The customer care agent may usevideo camera at the ATM 114 to verify the identification document andpresence of the customer at the ATM 114. Upon successful authenticationof the customer and verification of the customer's presence at the ATM114, the customer care agent may securely send the instruction(s) or thecommand(s) to the ATM to complete the prestaged transaction or thetransaction for which the customer requested help from the customer careagent.

FIG. 2A illustrates a screen of a mobile application at the UE device102 according to an embodiment. The screen shown in FIG. 2A may bedisplayed on the UE device 102 when the customer launches the mobileapplication and completes the login process for the mobile application.To complete the login process of the mobile application, the customermay enter a user id and password. The user id may be a phone number, anemail address, or an alphanumeric string. The customer may also completethe login process using biometric information such as a fingerprint, athumbprint, or a scan of an iris. The login process may also requiretwo-factor authentication, in which a code may be sent to a phone numberassociated with the combination of user id and password. The customerthen enters the received code to complete the login process. The screenshown in FIG. 2A may be displayed when the customer accesses thechecking account associated with the account on the mobile application.The customer may check available balance, check available rewardpoints/miles, pay bills, transfer money between different accounts atthe bank, send money to another party/person, or deposit cheque usingthe camera of the UE device 102. The customer may also see recenttransactions. The customer may set up a transaction to execute later atthe ATM, i.e., the prestaged transaction described above, selecting “GetCash at an ATM” option.

FIG. 2B illustrates a screen of the mobile application at the UE device102 according to an embodiment. Particularly, the screen shown in FIG.2B may be displayed when the customer selects the option describedabove, with reference to FIG. 2A, to set up the prestaged transaction.The screen shown in FIG. 2B may be displayed when the customer selectsan option to transfer money between accounts at the bank, deposit acheque using the camera at the UE device 102, or send money to the otherparty/person. For example, the customer wants to set up the prestagedtransaction to withdraw cash, and so the customer selects the accountfrom which to withdraw the money. As shown in FIG. 2B, the customer hastwo accounts and may choose one of the account to withdraw money.

FIG. 2C illustrates a screen of the mobile application at the UE device102 according to an embodiment. As shown in FIG. 2C, the customerselects a checking account to withdraw money using the prestagedtransaction. The customer may select the amount to withdraw fromprepopulated recommended options or may enter the amount manually.

FIG. 2D illustrates a screen of the mobile application at the UE device102 according to an embodiment. As shown in FIG. 2D, the customer hasselected the account to withdraw money from and the amount of money. Thecustomer may be asked to confirm the transaction. When the customerconfirms the transaction, for example, selecting or pressing “ConfirmDetails” on the screen of the UE device 102, as described the details ofthis transaction may be communicated to the micro-service repository 106and/or the cardless services 108 over the secure interface 104 using oneor more API messages. The micro-service repository 106 and/or thecardless services 108 may authorize the prestaged transaction asdescribed above, and send a message to the UE device 102 as shown inFIG. 2E if the prestaged transaction is authorized.

FIG. 2E illustrates a screen of the mobile application at the UE device102 according to an embodiment. As shown in FIG. 2E, the prestagedtransaction set up by the customer is authorized, and, therefore, thecustomer may be asked what needs to be done next to complete theprestaged transaction. As shown in FIG. 2E, the message may indicate theprestaged transaction is valid up to a specific configurable time,which, for example, maybe 48 hours or 24 hours from the authorization ofthe prestaged transaction. The message may also indicate to the customerthat the customer needs to go to an ATM and scan the machine readableimage, for example, a QR code, being displayed on the ATM to completethe prestaged transaction.

FIG. 2F illustrates a screen of the mobile application at the UE device102 according to an embodiment. The screen shown in FIG. 2F may bedisplayed when the customer is at the ATM 114 with the UE device 102.Because the customer has set up the prestaged transaction using themobile application on the UE device 102, and the prestaged transactionhas been authorized, the customer may be guided how to enable the camera103 to scan the machine readable image 116 displayed on the UE device102. The ATM 114 may also transmit Wi-Fi and/or Bluetooth beacon signalsto send a notification to a mobile device, such as the UE device 102, tosend a notification to invite the customer to use the ATM. Accordingly,when the UE device 102 arrives in the proximity of the ATM 114, the UEdevice 102 and the ATM 114 may communicate with each other using Wi-Fior Bluetooth.

FIG. 2G illustrates a screen of the mobile application at the UE device102 according to an embodiment. Once the machine readable image 116displayed on the UE device 102 is scanned by the camera 103, the screenshown in FIG. 2G may be displayed, which may provide the customer withan update of the status of the transaction being performed. The updateof the status of the transaction being performed may be displayed on thedisplay of the ATM 114 as well.

FIG. 2H illustrates a screen of the mobile application at the UE device102 according to an embodiment. The screen shown in FIG. 2H may bedisplayed to remind the customer to take cash from the ATM 114. Thecustomer may be reminded to take the cash by a similar message on thedisplay of the ATM 114 as well.

FIG. 3A illustrates a flowchart 300 of a process for using a third partydynamic quick response (QR) code on a personal mobile device to completea transaction at an ATM according to an embodiment. The micro-servicerepository 106, the cardless services 108, and the pairing services 110may be on a single server or may be distributed on different servers.Irrespective of whether the micro-service repository 106, the cardlessservices 108, and the pairing services 110 are on the single server oron different servers, together they form a backend system. FIG. 3A is aflowchart 300 of the process for using a third party dynamic quickresponse (QR) code on a personal mobile device to complete a transactionat an ATM from the backend system perspective. While the disclosure usedATM to describe various embodiments, the disclosure applies to a kioskto serve a customer, for example, to deliver a ticket and/or a boardingpass, a preordered lunch, etc.

In some embodiments, at step 302, as described above, information of theprestaged transaction may be received by the backend system, i.e., themicro-service repository 106 and/or the cardless services 108, from theUE device 102 over the secure interface 104 as described above. Asdescribed above, upon successful authorization of the prestagedtransaction, the customer may be asked to go to the ATM to complete theprestaged transaction as described above.

In some embodiments, at step 304, after successful set up of theprestaged transaction on the mobile application on the UE device 102, amachine readable image 116 may be generated by the pairing service asdescribed above. The machine readable image 116 may then be transmittedto the UE device 102. Therefore, when the customer reaches the ATM 114,the customer may pose the machine readable image 116 on the UE devicebefore the camera 103. In some embodiments, at step 304, the prestagedtransaction may be determined based on receiving additional scannedimages from the display on the UE device and scanned by the camera 103.By way of non-limiting example, the prestaged transaction may beidentified based on not just a single machine readable image 116displayed on the UE device 102, but the prestaged transaction may beidentified based on a series of different machine readable imagesdisplayed on the UE device 102.

In some embodiments, at step 306, the ATM 114 may send an API message(s)to the backend system. The API message(s) from the ATM 114 may includethe machine readable image 116 scanned by the camera 103 and the ATMidentifier assigned to the ATM 114 by the pairing service 110.

In some embodiments, at step 308, based on the received image from theATM 114 in the API message(s) at step 306, the backend system mayidentify or determine previously set up and authorized the prestagedtransaction. The backend system may identify the ATM, and its physicallocation based on the ATM identifier in the API message(s) received atstep 306.

In some embodiments, at step 310, the backend system may authorize theprestaged transaction again. The reauthorization may be to verify thatthe prestaged transaction would be successful under any changedcircumstances since the prestaged transaction was set up and authorized.

In some embodiments, at step 312, upon identifying the ATM at which thecustomer is present to complete the prestaged transaction identified atstep 306, the backend system may send appropriate API message(s) to theATM, which in our example is ATM 114. The API message(s) to the ATM 114may be to dispense money according to the authorized prestagedtransaction. The API message(s) to the ATM 114 may be to deposit cash atthe ATM 114.

FIG. 3B illustrates a flowchart 300 of a process for using a third partydynamic quick response (QR) code on a personal mobile device to completea transaction at an ATM according to an embodiment. Particularly, FIG.3B shows a flowchart 300 of the process for using a third party dynamicquick response (QR) code on a personal mobile device to complete atransaction at an ATM from the ATM 114 perspective. The step numbers donot indicate an order in which the method step occurs. At step 314, whenthe customer poses the machine readable image 316 on the UE device 102before the camera 103, the ATM 114 may scan the machine readable image316 displayed on the UE device using the camera 103. At step 316, theATM 114 may send an API message(s) to the backend system. The APImessage(s) sent from the ATM 114 may include the scanned image and anATM identifier assigned to the ATM 114 by the pairing server 110 asdescribed above. After successful verification of the details receivedin the API message(s) from the ATM 114 at step 316, the backend systemmay send an appropriate command using an API message(s) to the ATM 114to complete the prestaged transaction as shown in FIG. 3B at step 318.

FIG. 3C illustrates a flowchart 300 of a process for using a third partydynamic quick response (QR) code on a personal mobile device to completea transaction at an ATM according to an embodiment. Particularly, FIG.3C shows a flowchart 300 of the process for using a third party dynamicquick response (QR) code on a personal mobile device to complete atransaction at an ATM from the customer or UE device 102 perspective.The step numbers do not indicate an order in which the method stepoccurs. At step 320, the customer using the mobile application installedon the UE device 102 may set up the prestaged transaction. The prestagedtransaction may be authorized, and the customer may be shown a messageon the UE device 102 to visit an ATM to complete the prestagedtransaction as described above. At step 322, the customer may visit anATM, for example, the ATM 114, and may pose the machine readable imagedisplayed on the display of the UE device 102 before the camera 103 tocomplete the prestaged transaction. The machine readable image 116 maybe scanned and sent in the API message(s) to the backend system by theATM 114, as described above. The backend system may then send the APImessage(s) to the ATM 114 to complete the authorized prestagedtransaction.

FIG. 4 illustrates an exemplary computer system according to anembodiment.

Various embodiments may be implemented, for example, using one or morewell-known computer systems, such as a computer system 400, as shown inFIG. 4. One or more computer systems 400 may be used, for example, toimplement any of the embodiments discussed herein, as well ascombinations and sub-combinations thereof. The computer systems 400 maybe used for the micro-service repository 106, the cardless services 108,and/or the pairing service 110 described above.

The computer system 400 may include one or more processors (also calledcentral processing units, or CPUs), such as a processor 404. Theprocessor 404 may be connected to a communication infrastructure or bus406.

The computer system 400 may also include user input/output device(s)403, such as monitors, keyboards, pointing devices, etc., which maycommunicate with communication infrastructure 406 through userinput/output interface(s) 402.

One or more of processors 404 may be a graphics processing unit (GPU).In an embodiment, a GPU may be a processor that is a specializedelectronic circuit designed to process mathematically intensiveapplications. The GPU may have a parallel structure that is efficientfor parallel processing of large blocks of data, such as mathematicallyintensive data common to computer graphics applications, images, videos,etc.

The computer system 400 may also include a main or primary memory 408,such as random access memory (RAM). Main memory 408 may include one ormore levels of cache. Main memory 408 may have stored therein controllogic (i.e., computer software) and/or data.

The computer system 400 may also include one or more secondary storagedevices or memory 410. The secondary memory 410 may include, forexample, a hard disk drive 412 and/or a removable storage device ordrive 414. The removable storage drive 414 may be a floppy disk drive, amagnetic tape drive, a compact disk drive, an optical storage device,tape backup device, and/or any other storage device/drive.

The removable storage drive 414 may interact with a removable storageunit 418. The removable storage unit 418 may include a computer-usableor readable storage device having stored thereon computer software(control logic) and/or data. The removable storage unit 418 may be afloppy disk, magnetic tape, compact disk, DVD, optical storage disk,and/any other computer data storage device. The removable storage drive414 may read from and/or write to the removable storage unit 418.

The secondary memory 410 may include other means, devices, components,instrumentalities or other approaches for allowing computer programsand/or other instructions and/or data to be accessed by the computersystem 400. Such means, devices, components, instrumentalities or otherapproaches may include, for example, a removable storage unit 422 and aninterface 420. Examples of the removable storage unit 422 and theinterface 420 may include a program cartridge and cartridge interface(such as that found in video game devices), a removable memory chip(such as an EPROM or PROM) and associated socket, a memory stick and USBport, a memory card and associated memory card slot, and/or any otherremovable storage unit and associated interface.

The computer system 400 may further include a communication or networkinterface 424. The communication interface 424 may enable the computersystem 400 to communicate and interact with any combination of externaldevices, external networks, external entities, etc. (individually andcollectively referenced by reference number 428). For example, thecommunication interface 424 may allow the computer system 400 tocommunicate with the external or remote devices 428 over communicationspath 426, which may be wired and/or wireless (or a combination thereof),and which may include any combination of LANs, WANs, the Internet, etc.Control logic and/or data may be transmitted to and from the computersystem 400 via the communication path 426.

The computer system 400 may also be any of a personal digital assistant(PDA), desktop workstation, laptop or notebook computer, netbook,tablet, smartphone, smartwatch or other wearable, appliance, part of theInternet-of-Things, and/or embedded system, to name a few non-limitingexamples, or any combination thereof.

The computer system 400 may be a client or server, accessing or hostingany applications and/or data through any delivery paradigm, includingbut not limited to remote or distributed cloud computing solutions;local or on-premises software (“on-premise” cloud-based solutions); “asa service” models (e.g., content as a service (CaaS), digital content asa service (DCaaS), software as a service (SaaS), managed software as aservice (MSaaS), platform as a service (PaaS), desktop as a service(DaaS), framework as a service (FaaS), backend as a service (BaaS),mobile backend as a service (MBaaS), infrastructure as a service (IaaS),etc.); and/or a hybrid model including any combination of the foregoingexamples or other services or delivery paradigms.

Any applicable data structures, file formats, and schemas in thecomputer system 400 may be derived from standards including but notlimited to JavaScript Object Notation (JSON), Extensible Markup Language(XML), Yet Another Markup Language (YAML), Extensible Hypertext MarkupLanguage (XHTML), Wireless Markup Language (WML), MessagePack, XML UserInterface Language (XUL), or any other functionally similarrepresentations alone or in combination. Alternatively, proprietary datastructures, formats, or schemas may be used, either exclusively or incombination with known or open standards.

In accordance with some embodiments, a tangible, non-transitoryapparatus or article of manufacture comprising a tangible,non-transitory computer useable or readable medium having control logic(software) stored thereon may also be referred to herein as a computerprogram product or program storage device. This includes, but is notlimited to, the computer system 400, the main memory 408, the secondarymemory 410, and the removable storage units 418 and 422, as well astangible articles of manufacture embodying any combination of theforegoing. Such control logic, when executed by one or more dataprocessing devices (such as the computer system 400), may cause suchdata processing devices to operate as described herein.

Based on the teachings contained in this disclosure, it will be apparentto persons skilled in the relevant art(s) how to make and useembodiments of this disclosure using data processing devices, computersystems and/or computer architectures other than that shown in FIG. 4.In particular, embodiments can operate with software, hardware, and/oroperating system implementations other than those described herein.

The present invention has been described above with the aid offunctional building blocks illustrating the implementation of specifiedfunctions and relationships thereof. The boundaries of these functionalbuilding blocks have been arbitrarily defined herein for the convenienceof the description. Alternate boundaries can be defined so long as thespecified functions and relationships thereof are appropriatelyperformed.

The foregoing description of the specific embodiments will so fullyreveal the general nature of the invention that others can, by applyingknowledge within the skill of the art, readily modify and/or adapt forvarious applications such specific embodiments, without undueexperimentation, without departing from the general concept of thepresent invention. Therefore, such adaptations and modifications areintended to be within the meaning and range of equivalents of thedisclosed embodiments, based on the teaching and guidance presentedherein. It is to be understood that the phraseology or terminologyherein is for the purpose of description and not of limitation, suchthat the terminology or phraseology of the present specification is tobe interpreted by the skilled artisan in light of the teachings andguidance.

The breadth and scope of the present invention should not be limited byany of the above-described exemplary embodiments but should be definedonly in accordance with the following claims and their equivalents.

The claims in the instant application are different than those of theparent application or other related applications. The Applicant,therefore, rescinds any disclaimer of claim scope made in the parentapplication or any predecessor application in relation to the instantapplication. The Examiner is therefore advised that any such previousdisclaimer and the cited references that it was made to avoid, may needto be revisited. Further, the Examiner is also reminded that anydisclaimer made in the instant application should not be read into oragainst the parent application.

What is claimed is:
 1. A method, comprising: receiving, by one or morecomputing devices, a message from a kiosk, wherein the message comprisesan image from a display on a user equipment (UE) device as scanned by acamera on the kiosk, and a kiosk identifier for the kiosk, wherein theimage is associated with a prestaged transaction; associating, by theone or more computing devices, the prestaged transaction with the kiosk,wherein the prestaged transaction is determined based on the scannedimage in the message, and wherein the kiosk is determined based on thekiosk identifier in the message; and sending, by the one or morecomputing devices, a command to the kiosk based on the kiosk identifierto execute the prestaged transaction.
 2. The method of claim 1, furthercomprising: comparing a physical location of the UE device with aphysical location of the kiosk; and rejecting the prestaged transactionin response to the physical location of the UE device not matching withthe physical location of the kiosk.
 3. The method of claim 2, whereinthe physical location of the kiosk is determined based on the kioskidentifier.
 4. The method of claim 1, wherein the prestaged transactionis further determined based on receiving, by the one or more computingdevices, from the kiosk a plurality of additional images from thedisplay on the UE device as scanned by the camera on the kiosk and thekiosk identifier.
 5. The method of claim 1, further comprising:authorizing, by the one or more computing devices, the prestagedtransaction based on comparison of an owner of the phone numberassociated with the UE device to be same as an owner of an accountassociated with the prestaged transaction.
 6. The method of claim 1,further comprising: in response to a failure in executing the prestagedtransaction, sending, by the one or more computing devices, anotification on a mobile application of a mobile device of an agent toassist with the prestaged transaction.
 7. The method of claim 1, furthercomprising: in response to a failure in executing the prestagedtransaction, displaying, by the one or more computing devices, a helpmessage on a display of the kiosk to complete the prestaged transaction.8. The method of claim 1, further comprising: authorizing, by the one ormore computing devices, the prestaged transaction based on performing atwo-factor authentication with a phone number associated with an accountof the prestaged transaction.
 9. The method of claim 1, furthercomprising: in response to a determination that the prestagedtransaction is outside of a preset policy boundary, overriding, by theone or more computing devices, the preset policy to authorize theprestaged transaction based on verification of information associatedwith an account of the prestaged transaction.
 10. A system, comprising:a memory for storing instructions; and one or more processors,communicatively coupled to the memory, configured to execute theinstructions, the instructions causing the one or more processors to:receive a message from a kiosk, wherein the message comprises an imagefrom a display on a user equipment (UE) device as scanned by a camera onthe kiosk, and a kiosk identifier for the kiosk, and wherein the imageis associated with information of a prestaged transaction; associate theprestaged transaction with the kiosk, wherein the prestaged transactionis determined based on the scanned image in the message, and wherein thekiosk is determined based on the kiosk identifier in the message; andsend a command to the kiosk based on the kiosk identifier to execute theprestaged transaction.
 11. The system of claim 10, wherein the one ormore processors are further configured to: compare a physical locationof the UE device with a physical location of the kiosk; and reject theprestaged transaction in response to the physical location of the UEdevice not matching with the physical location of the kiosk, wherein thephysical location of the kiosk is determined based on the kioskidentifier.
 12. The system of claim 10, wherein to determine theprestaged transaction, the one or more processors are further configuredto receive from the kiosk a plurality of additional images from thedisplay on the UE device as scanned by the camera on the kiosk and thekiosk identifier.
 13. The system of claim 10, wherein the one or moreprocessors are further configured to: authorize the prestagedtransaction based on comparison of an owner of the phone numberassociated with the UE device to be same as an owner of an accountassociated with the prestaged transaction.
 14. The system of claim 10,wherein the one or more processors are further configured to: inresponse to a failure in executing the prestaged transaction, send anotification on a mobile application of a mobile device of an agent toassist with the prestaged transaction.
 15. The system of claim 10,wherein the one or more processors are further configured to: inresponse to a failure in executing the prestaged transaction, display ahelp message on a display of the kiosk to complete the prestagedtransaction.
 16. The system of claim 10, wherein the one or moreprocessors are further configured to: authorize the prestagedtransaction based on performing a two-factor authentication with a phonenumber associated with an account of the prestaged transaction.
 17. Thesystem of claim 10, wherein the one or more processors are furtherconfigured to: in response to a determination that the prestagedtransaction is outside of a preset policy boundary, override the presetpolicy to authorize the prestaged transaction based on verification ofinformation associated with an account of the prestaged transaction. 18.The system of claim 10, wherein the one or more processors are furtherconfigured to: unlock a feature of the mobile application at the UEdevice based on verification of information associated with an accountof the prestaged transaction.
 19. A non-transitory, tangiblecomputer-readable device having instructions stored thereon that, whenexecuted by at least one computing device, causes the at least onecomputing device to perform operations comprising: receiving a messagefrom a kiosk, wherein the message comprises an image from a display on auser equipment (UE) device as scanned by a camera on the kiosk, and akiosk identifier for the kiosk, and wherein the image is associated withinformation of a prestaged transaction; associating the prestagedtransaction with the kiosk, wherein the prestaged transaction isdetermined based on the scanned image in the message, and wherein thekiosk is determined based on the kiosk identifier in the message; andsending a command to the kiosk based on the kiosk identifier to executethe prestaged transaction.
 20. The non-transitory, tangiblecomputer-readable device of claim 19, wherein operations furthercomprise: comparing a physical location of the UE device with a physicallocation of the kiosk; and rejecting the prestaged transaction inresponse to the physical location of the UE device not matching with thephysical location of the kiosk, wherein the physical location of thekiosk is determined based on the kiosk identifier.